-
Notifications
You must be signed in to change notification settings - Fork 468
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrate CaptureArbitrumStorageGet/Set into the prestate tracer #2602
base: master
Are you sure you want to change the base?
Integrate CaptureArbitrumStorageGet/Set into the prestate tracer #2602
Conversation
…toragegetset-prestatetracer
…toragegetset-prestatetracer
system_tests/debugapi_test.go
Outdated
if !cond { | ||
Fatal(t, msg...) | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test should look at things that happen before EVM execution. I think easiest is an arbos upgrade. Might be other possibilities.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
arbos upgrade through ScheduleArbOSUpgrade
does make changes to arbitrum storage but the tracing scenario set by default when calling precompiles is tracingDuringEVM, so these changes don't get picked up
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added the test to check for the storage accesses
… the prestateTracer's trace
This PR implements
CaptureArbitrumStorage[Get]Set
methods forprestateTracer
capturing changes that ArbOS makes to storage outside EVM execution, these weren't picked up by theprestateTracer
before.Arbos
Storage
object callsRecordStorage[Get]Set
functions to capture tracing of reads and writes of key-value pairs, meaning the SLOAD/SSTORE opcodes tracing in these functions during scenarioTracingDuringEVM
has no impact at all as the caller address (scope.Contract) and the key being passed don't associate with each other, instead the key corresponds to types.ArbosStateAddress.To solve this issue, we currently call
CaptureArbitrumStorage[Get]Set
regardless of the tracing scenario and call opcode tracing additionally if the scenario isTracingDuringEVM
to preserve functionality of other tracers that haven't yet implementedCaptureArbitrumStorage...
methods. Notice that SLOAD/SSTORE opcode tracing has no effect on prestate tracer due to the above stated issue and callingCaptureArbitrumStorage...
methods first yields correct results.Pulls in geth- OffchainLabs/go-ethereum#352
Resolves NIT-2733